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REMARKS 

Claims 41, 51, 61, 71, 99, 101, 111, 121, 131, 141 and 142 have been amended to 
clarify the invention and better define the invention over the art. No new matter has been 
added. 

Turning first to the rejections of claims 141 and 142 as directed to non-statutory subject 
matter under 35 U.S.C. §101, these claims have been amended to clarify the several steps that 
produce the "usefiil, concrete and tangible result" required to satisfy §101, pursuant to the State 
Street decision, 149 F.3d at 1373. In particular, Applicant teaches the formats, details and uses 
of the information that can be substituted for the CUSTOMER NAME and DISCRETIONARY 
DATA fields in a legacy ACH transaction format. When the ACH record format was initially 
formulated years ago, the CUSTOMER NAME field was supposed to be a secondary or 
auxiliary validation mechanism for the ACCOUNT NUMBER field. For an account number 
"123", the common customer name "Jones" or "Smith" is not exactly a definitive secondary 
validation, even if initials or a first name is included in this limited 15 character field. If one 
has a foreign last name that is longer than 1 5 characters, then the truncated name or a 
contracted form of the name may not be sufficient to discern multiple instances within the same 
family name that are holding separate accounts at the same institution. Even if names are 
contracted, the source encoding process may not be the same as the destination decoding 
process to provide an automated form of secondary validation. In an automated data capture 
process, the customer name may not (almost never) always be available to insert into the 
CUSTOMER NAME field in an ACH record. In summary, as a secondary validation 
mechanism, the CUSTOMER NAME field cannot be used for its originally intended design in 
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the great majority of circumstances. Applicant teaches an explicit use for the CUSTOMER 
NAME and DISCRETIONARY DATA fields in the legacy ACH transaction format that indeed 
produces "a useful, concrete and tangible result," namely, providing end-to-end absolute 
benchmark information to the destination biller that is a common data point (transaction ID, 
date, time and place of payment) for all parties (the customer, the retailer, the bill payment 
network and the destination biller) involved in Applicant's bill payment transaction. While 
other inventions claim commonality in collecting date and time of payment (a very common 
procedure to time stamp all collected information, no matter what it is, as a rule of "just plain 
common sense"), none of the other inventions either describe what the collected data will be 
used for or how this data will eventually be transferred to the specified target - in this case the 
destination biller. Just because the biller may receive date and time of the customer retail 
payment in a proprietary data format, it is not incumbent that the biller use this information 
when crediting a customer account. Unless the biller receives coincident funds and payment 
data, legally, the biller only has to recognize a Regulation Z commitment as the legal minimum 
for all received bill payments. Applicant teaches a common data baseline that can be used for 
contractual commitments that favor the transaction consummation process. The customer gets 
a more favored payment date than the minimum Regulation Z legally recognized commitment, 
the biller has a quantitative means to measure and track service delivery of those transactions 
from the bill payment network and customer suspicion of artificially induced payment delays 
"somewhere in the network" are significantly reduced. These features are not taught anywhere 
else. For the foregoing reasons, it is believed that the §101 rejection as to claims 141 and 142 
has been traversed and therefore should be withdrawn. 
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Turning next to the rejection of claims 99-100 and 141-142 as indefinite under 35 
U.S.C. §112, second paragraph, claim 99 has been amended to clarify the steps of the claimed 
method. It is believed that this amendment traverses the indefiniteness rejection with regard to 
claim 99, as well as claim 100 depending therefi-om. Claims 141 and 142 have been amended 
to clarify that these claims are directed, respectively, to a method for including additional data 
in an ACH funds transfer, and a method for including additional data in an electronic funds 
transfer. It is believed that these amendments traverse the indefiniteness rejection with regard 
to claims 141 and 142, which Applicant respectfully submits should now be withdrawn. 

Turning now to the art rejections, and considering first the rejection of claims 41-43, 
45-53,55-63,65-73,75-92, 94, 96, 101-103, 105-113, 115-123, 125-133 and 135-140 as 
anticipated under 35 U.S.C. § 102(e) by Applewhite, U.S. Application Pub. No. 2003/0023553 
("Applewhite"), Applicant respectfully submits that Applewhite does not teach an operable 
invention and is non-enabling, as argued above in the "Introductory Comments" section, and 
therefore cannot properly be used to maintain a rejection of Applicant's claims. Moreover, 
claims 41, 51, 61, 71, 101, 1 1 1, 121, and 131 have all been amended to clarify that the bar code 
embodies an algorithmic signature identifying the bar code as being proprietary to the bill 
payment paradigm of the present invention, without requiring any additional information to 
disambiguate the bar code from the plethora of other bar codes that exist within the retail 
market. Support is provided in the specification at p. 19, line 14 through p. 28, line 19. 
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the form of grocery items or internal biller-printed bar codes on the biller's invoice. Therefore, 
Applicant respectfully submits that the anticipation rejection of claims 41,51,61,71, 101, 111, 
121, and 131 should be withdrawn. Likewise, the anticipation rejection should also be 
withdrawn as to claims 42, 43, 45-50, 52, 53, 55-60, 62, 63, 65-70, 72, 73, 75-90, 92, 94, 96, 
102, 103, 105-110, 112, 113, 115-120, 122, 123, 125-130, 132, 133, and 135-140 depending 
therefrom, which are patentable for the reasons given with respect to their parent claims, as 
well as for their own additional limitations. 

Considering next the rejection of claims 81-92 as anticipated under 35 U.S.C. §102(e) 
by Applewhite, Applicant respectfully submits that Applewhite does not teach an operable 
invention and is non-enabling, as argued above in the "Introductory Comments" section, and 
therefore cannot properly be used to maintain a rejection of Applicant's claims. Moreover, 
independent claims 8 1 and 82 both require an accounts receivable system adapted to credit an 
account corresponding to the payor in the amount of payment as of the date and time the bill 
payment system received the payor's payment. Even if Applewhite were enabling, Applewhite 
fails to teach an accounts receivable system that provides credit for payment as of the date and 
time payment was made. Regarding claims 83 and 84, both of these claims require 
concomitant transfer of funds and data. Even if Applewhite were enabling, Applewhite's EFT 
or management computer 315, whether or not it formulates the data into an electronic funds 
transfer format, does not have the capability of submitting valid data files to the Federal 
Reserve ACH network (or any other financial network for that matter) as third-party 
submission entities. As external non-responsible entities to the retailer organization, they do 
not have the authority to submit ACH credit/debit data on behalf of the retailer account. To the 
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contrary, claims 83 and 84 explicitly require concomitant remission of customer payment data 
and good electronic funds, which Applewhite fails to teach. Claims 85-92 depend from claims 
81-84 and are patentable for the reasons given with respect to their parent claims, as well as for 
their own additional limitations. Therefore, Applicant respectfully submits that the 
obviousness rejection of claims 81-92 is in error and should be withdrawn. 

Considering now the rejection of claims 44, 54, 64, 74, 104, 1 14, 124 and 134 under 35 
U.S.C. §103(a) as obvious over Applewhite in view of Finocchio, U.S. Patent No. 5,317,135 
("Finocchio"), Applicant respectfully submits that this rejection is in error. First, these claims 
are all patentable as depending from patentable parent claims 41, 51, 61, 71, 101, 111, 121 and 
13 1, as argued above, due to the deficiencies of Applewhite. Second, Finocchio is not 
analogous art, as Finocchio teaches a method and apparatus for validating instant-win lottery 
tickets, and not a financial transaction system. Thus, one skilled in the art of financial 
transaction systems would not have been aware of the teachings of Finocchio. Moreover, the 
Examiner has not set forth a prima facie case for obviousness, as the Examiner has provided no 
motivation for combining the teachings of Finocchio with teachings regarding financial 
transaction systems. In particular. Applicant notes that Finocchio uses a validation mechanism 
to prevent fraud in a winning lottery ticket situation. Finocchio's system employs a mechanism 
where a central authority has control over bar codes used in his system, with regard both to 
printing and to data detection. To the contrary, there is no central authority in Applicant's 
invention that has direct printing and data detection control over the bar code mechanism being 
employed; the central authority merely provides to the biller certain bar code print 
specifications that must fall within industry standards, and the central authority is not involved 
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in the printing of invoices or the data detection process itself. In a winning lottery ticket 
situation, there is ample reason to believe and to protect against the fraud that will be attempted 
by the general public because of the potentially high value a winning lottery ticket might have. 
In Applicant's bill payment situation, it would be highly unusual and unlikely for an individual 
to try to fraudulently make a bill payment that intentionally credits someone else's account. In 
short, Applicant's bar code is a disambiguation mechanism, whereas the primary purpose 
Finocchio bar code design is a fraud prevention mechanism. For non-winning lottery tickets, 
the use of the Finocchio bar code fraud prevention mechanism is of no consequence and is not 
used in every case. On the other hand, where customer bill payments are submitted at retail for 
payment, Applicant's bar code is used every time. Thus, even if Finocchio were analogous art, 
one skilled in the art would still not have been motivated to apply Finocchio 's teachings to the 
present invention, and moreover, one skilled in the art could still not arrive at Applicant's 
invention by employing, in part, the teachings of Finocchio. For these reasons, the obviousness 
rejection as to claims 44, 54, 64, 74, 104, 1 14, 124 and 134 is in error and should be 
withdrawn. 

Now considering the rejection of claims 141 and 142 under 35 U.S.C. §103(a) as 
obvious over Thomas et al., U.S. Patent No. 6,317,745 ("Thomas"), as noted above. Applicant 
has amended these claims to clarify that these claims are directed, respectively, to a method for 
including additional data in an ACH funds transfer, and a method for including additional data 
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Applicant's specified Biller ID) and replacing the true bank routing account information for the 
destination biller. This is an old and common data processing technique to protect confidential 
financial information where ACH UID or Biller ID might be the "public" face but true bank 
routing and account remittance information is the "private" face information that is required to 
remit funds through the Federal Reserve ACH network. In claims 141 and 142, Applicant 
claims information substitution in the CUSTOMER NAME and DISCRETIONARY DATA 
fields, which is an entirely different matter altogether. These claims do not embody the 
concept of aliasing information that is dependent on either a public or private situation 
operational mode. Thomas teaches his aliasing techniques for INTERMEDIATE files that are 
exchanged between the originator and a trusted third-party remittance organization. The 
trusted third-party submitter remits data files in the standard "vanilla" ACH format. And while 
these financial data files, containing customer payment data, may have similar characteristics 
of the standard ACH format, ANY data format proprietary or otherwise, exchanged between 
intermediary networks is acceptable. What Thomas does not teach is the substitution of 
relevant information in the final ACH format to the destination recipient that has the capability 
of securing a more favored customer payment date by the creditor. The reason for this 
omission is very obvious when one considers the vast financial benefits that accrue to these 
intermediary networks firom the "floaf derived fi-om, intentional or otherwise, transmission 
delays and late payment penalties assessed by the billers. There is no incentive for these 
intermediate networks to expedite customer payment data and funds to the destination biller 
because these networks lose the financial float that is an inherent and critical feature of their 
profit margin business model. Destination billers have a similar "disincentive" to credit 
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customer accounts in a timely manner if there can be penalty assessments applied to customer 
accounts for payments intentionally delayed by as little as a few hours. In both of these cases, 
there is no common end-to-end traceability for transaction data traversing from the source 
retailer Point-of-Sale collection point to the destination biller Accounts Receivable deposit 
point. As discussed in Amendment A filed herein, typical late payment penalties of $29 per 
occurrence amounts to an APR rate that exceeds, by many magnitudes, the maximum legal 
usury rates imposed by all states. Applicant explicitly teaches modifications in the legacy 
ACH format, delivered to destination billers, a mechanism that can mitigate the penalfies 
charged by intermediate networks and destination billers. Large financial networks, such as 
VISA, Mastercard, and Checkfree would lose a large source of their enormous profit margins if 
Applicant's invention were implemented as an independent customer-centered financial 
remission network. Applicant explicitly teaches how the ACH legacy format can accommodate 
a customer payment date, time and place so that a subscription mechanism (biller sign-up) 
permits a contractual binding between the biller / customer (biller according the customer retail 
date and time of payment as creditor receipt of payment) and between the payment network / 
biller (biller receiving payments within a clearly defined service contract between the network 
and the biller that permits adequate time to marshal funds fi-om the retailer). Thomas, 
therefore, cannot render claims 141 and 142 obvious, and thus, it is respectfully submitted that 
the obviousness rejection with respect to these claims should be withdrawn. 
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A credit card payment form PTO-2038 authorizing a charge in the amount of $595.00 
for the RCE fee ($385.00) and Two-Month Extension fee ($210.00) accompanies this 
amendment. In the event there are any fee deficiencies or additional fees are payable, please 
charge them (or credit any overpayment) to our Deposit Account No. 08-1391 . 

Respectfully submitted, 




Kevin M. Drucker 
Attorney for Applicant 
Reg. No. 47,537 
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